Several methods for conducting payment transactions with the aid of a mobile telephone are known. The advantages of these methods are described in e.g. DE19903822.
These methods are generally designed in such a way that the transaction parties exchange data with a processing unit or, optionally, with each other.
In this connection, a distinction must be made between two types of method, which are referred to in the following as “A-type standard-compatible method” and “B-type future-dependent methods”.
“A-type standard-compatible methods” relate to those methods which can be implemented with the entire currently installed base of mobile telephones (i.e. with all or with the predominant majority of the mobile telephones/SIM module chip cards in circulation according to the state of the art) without necessitating the replacement or technical modification of said mobile telephones or SIM module chip cards.
“B-type future-dependent methods” relate to those methods that can only be implemented with special mobile telephones and SIM modules (generally of the latest model) which are still only in limited circulation or will only be marketed at a future point in time.
In type-B future-dependent methods the exchange of data generally occurs for at least one of the transaction parties via protocols and/or methods such as WAP (Wireless Application Protocol) or i-mode (predominantly in circulation in Japan), as well as via Java or SIM toolkit applications executed locally on a mobile telephone or SIM module chip card, the exchange of data occurring e.g. via GPRS (GSM Packet Radio Service).
A disadvantage of the type-B future-dependent methods is that they are dependent on the penetration and success of the technological infrastructure upon which they are based. An operator that would like to introduce such a method is faced with the choice of relying on a very small potential user basis or trying to induce potential users (e.g. with subsidies) to acquire new mobile telephone end devices. This represents a very large hurdle for the introduction of such a method.
Another disadvantage of the type-B future-dependent methods is that they can generally only be implemented in mobile wireless networks of a certain standard (such as e.g. GSM) and not with simple land line telephones.
In type-A standard-compatible methods the exchange of data generally occurs for at least one of the transaction parties via a live telephone connection with voice responses (e.g. by means of an IVR system (Interactive Voice Response)) and DTMF tone transmission (Dual Tone Multi-Frequency) or by SMS (Short Message System). These methods are generally effected through the transmission of the complete mobile telephone number (ANI/MSISDN) or a unique alias from the payer and/or payee to the payee and/or payer, the transmission of a permanently valid PIN code from the payer to a processing unit for authentication and, optionally, the transmission of a temporarily valid TAN code as proof of authorization and payment from the processing unit to the payer and from the payer to the payee.
One of these methods, the so-called Paybox method, is known from the second example of DE 199 03 822. This method is briefly illustrated here as an example of a type-A standard-compatible method:
The payer (called P in the following) first verbally transmits his mobile telephone number (ANI and/or MSISDN) or an alias clearly correlated to his mobile telephone number to the payee (recipient) (R). R then implicitly transmits his mobile telephone number by way of a telephone call from his mobile telephone, and explicitly transmits the mobile telephone number of P, as well as the amount to be paid, by way of DTMF tone transmission to a processing unit (PS). (A telephone connection between R and PS remains established until the final step). The processing unit then examines whether P is an authorized participant and whether the credit rating of P is sufficient for payment of the amount in question. The PS then initiates a call to the mobile telephone number of P. P accepts the call. A voice computer of the PS generates an acoustic message with the payment information (recipient, amount payable). To confirm and authorize the payment, P enters a PIN code using DTMF tone transmission. Upon successful authorization, the PS acoustically transmits to R a confirmation of payment via the still operative telephone connection.
The disadvantages of the Paybox method are above all the high telecommunications costs and the protracted duration of the transaction.
In the Paybox method the call from R to PS and the transmission of the data takes approx. 30 seconds. Of approximately the same length is the following call of PS to P including the announcement of the payment details and retrieval of the authorization PIN. The connection from the first call remains established during the second call. Altogether, telecommunication costs for 90 seconds of mobile telephone connections are incurred. If the transaction is effected by way of a toll-free telephone number and the operator of the PS bears the telecommunications costs, the latter currently incurs costs of approx. 30 euro cents as a result.
Thus, the implementation of the Paybox method is generally not commercially viable for smaller payment transactions.
Altogether, processing a transaction with the Paybox method takes approx. 75 seconds.
Thus, the implementation of this method in all time-critical mobile commerce application scenarios such as e.g. payments at point-of-sale terminals in retail is very problematic.
The disadvantages of the Paybox method illustrated with this example also apply in a similar manner to many other type-A standard-compatible methods.
E.g. the time restriction remains even when alternative transmission methods such as SMS are used. For example, the delivery speed of an SMS is not guaranteed and can often take up to 30 seconds, in some cases considerably longer. Additionally, depending on the method, the time required to enter and send an SMS has to be considered. (The same applies to certain type-B future-dependent methods, e.g. the use of WAP protocol—the time required to establish a connection, navigate and enter data is too long for use in time-critical mobile commerce scenarios).
Another disadvantage of said type-A standard-compatible method is that the complete mobile telephone number of the payer and/or payee has to be disclosed to the payer and/or payee. As a result, there is no anonymity between the transaction parties. The use of a telephone number alias (such as e.g. in the Paybox method) may provide a partial anonymity with respect to the actual mobile telephone number of the participant; however, principally, the unique identity of one transaction party is known to the other transaction party.
Another disadvantage of the use of a complete mobile telephone number or a telephone number alias is their length (generally 12 digits) and the resulting longer duration of entry and transmission, as well as the probability of mis-types.
Yet another disadvantage of said type-A standard-compatible method is the low degree of probative force and/or the risk of repudiation for the payer, the payee and the operator of the processing unit. One possibility for increasing probative force consists in the involvement of a “trusted third party”, i.e. an additional party recognized by the payer, the recipient and the operator of the processing unit. The telecommunications provider is particularly suitable to act as such an additional party. However, records of the content of data transmitted via an established telephone or WAP data connection, as well as of the content of an SMS, can generally not be kept by the telecommunications provider owing to legal regulations. Thus, generally, merely the telephone numbers of the communications partners, the time and duration of the communication as well as the amount of data transmitted are recorded. The fact that a transaction has been processed can thus principally be relatively readily proven. Should, however, a dispute with regard to the amount of the authorized amount arise, probative force is problematic. As a consequence, it is generally necessary in methods such as Paybox to e.g. send an SMS for confirmation purposes in order to reduce the probability of error and avoid future complaints, thereby generating further costs.
Another disadvantage of said type-A standard-compatible method is that it easy to make errors regarding the authorized amount. This risk arises because generally the amount is actively specified by one of the transaction parties only, and then merely passively confirmed by the other transaction party, e.g. after the amount has been displayed on the mobile telephone display or announced acoustically.
A method for billing internet transactions via mobile telephone systems is known from DE 199 46 539 A1. The association of retailer and customer in a payment gateway is accomplished using a temporary IP address of the mobile telephone of the customer. This IP address is namely transmitted to the payment gateway by both customer and retailer. The disadvantage of this method is that the matching of the temporary IP address of the mobile telephone subscriber with his MSISDN has to be effected via an MSISDN-IP databank, which makes the implementation of the method difficult, if not impossible for a payment gateway operator that is independent of the mobile telephone provider. Another disadvantage of this method is that the customer has to have a WAP-capable mobile wireless device at his disposal; the method is thus a “type-B future-dependent method” (see above). In addition, the establishment of a WAP internet connection is very time-consuming, and, therefore, the method is not suitable for most payment scenarios. Moreover, this method has the disadvantage that a relatively sizeable data set, namely the temporary IP address of the mobile wireless subscriber, must be transmitted for correlating retailer and customer. Finally, correlating the IP addresses entering the payment gateway is complex, as a very large number of IP addresses may have to be compared.
Finally, a method for authorizing the payment of goods offered on the Internet is known from EP 1 081 919 A1. Here, correlating customer and provider is effected with an authorization comparator by means of a transaction code that is generated by the provider and transmitted to the customer. This, however, gives rise to the disadvantage that the handling of the transaction codes, which vary for both transaction parties from transaction to transaction, is inherently complex. As a result, the, in total, triple transmission of the transaction code (from the provider to the authorization comparator, from the provider to the customer and from the customer to the authorization comparator) is highly prone to error. To safeguard against a transaction code error (and unintentionally “mismatching” another open transaction), or even to safeguard against a general error e.g. with regard to the authorized sum, a further enquiry from the authorization comparator to the customer is necessary (see column 8 lines 47-55 of the published patent application) before the transaction can be conducted. This renders the method considerably slower and more expensive so that almost all of the disadvantages of the above-mentioned Paybox method also apply to this method. Moreover, the generation of a reliably unique transaction code is so complex that a special algorithm at the retailer's terminal becomes a practical necessity, which entails a restriction to e.g. Java-capable mobile telephones. Thus, this is also one of the disadvantageous “type-B future-dependent methods” (see above). Finally, the disadvantage also arises here that a relatively sizeable data set must be transmitted for correlating retailer and customer while the required examination is complex, as a very large number of transaction codes may have to be compared.